Internet Tools (InfoMagic)/Internet Tools.iso/dos_win/winsock/hacklist/94-04.Z/94-04/000005_ICH211@ZAM001.Z…KFA-JUELICH.DE_Wed Apr 6 13:24:53 1994.msg

Internet Message Format | 1994-04-30 | 7KB

Received: from zam001.zam.kfa-juelich.de by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA19461; Wed, 6 Apr 1994 05:40:24 -0400
Message-Id: <[e-mail]>
Received: from DJUKFA11 by ZAM001.ZAM.KFA-JUELICH.DE (IBM VM SMTP V2R2)
   with BSMTP id 2542; Wed, 06 Apr 94 11:40:25 +0200
Date:         Wed, 06 Apr 94 11:24:53 +0200
From: Thomas Heil <[e-mail]>
Organization: Forschungszentrum Juelich GmbH - Institut fuer Chemie 2
Subject:      Re: Closing and reusing sockets
To: Multiple recipients of list <[e-mail]>
In-Reply-To:  Message of Tue, 5 Apr 1994 09:13:03 -0400 from <[e-mail]>

On Tue, 5 Apr 1994 09:13:03 -0400 you said:
>> From: [e-mail]
>
>> [loads of stuff -- should one call bind?]
>
>> Now, the twist from your last sentence (above) is that you want to
>> bind() and connect() from a free reserved port - only in this case is
>>                             ---- ======== ----
>> it necessary or recommended to call bind() before connect().
>
>Thanks for this confirmation.
>
>> To avoid WSAEADDRINUSE errors, you must make sure a socket is fully closed
>> before you can connect _from_the_same_port_number_ to the same remote
>> machine listening on the _same_remote_port_ - possibly by blocking in
>> a lingering close, or using linger to hard-close the connection when
>> you're done the first time.
>
>This is roughly what I said in the very first message in this thread --
>hard-closing
>the socket makes the problem go away.  I guess that waiting for the close to
>complete (probably not actually blocking, given that we're all nice cooperative
>Windows programmers) is gentler, but it would complicate the exit logic of the
>program rather a lot.
>
>This would all be a lot easier if we could rely on bind() giving EADDRINUSE
>so that the next port could be used instead, and leave the stack to
>get on with closing down the old one quietly.
>
>Bryan.
>

I had the same problem with unreliable bind()s (with FTP Software's Winsock)
in my WLPR.DLL which is used by my LPR client and Windows Spooler. The LPR
protocol demands the client to bind to a free reserved port number, So I
took the sample code from the WinSock specs. The bind() always succeeded,
and the connect() bombed with EADDRINUSE when there was an older connection
lingering. So I put a linger(1,0) before the closesocket() call. This forced
the connections to close completely, but it had the nasty side effect to
give the LPR server a "connection reset" error, which caused a lot of
LPDs to die (meaning the spool job went into the queue but was not sent to the
printer).
I got the same reply from FTP Software about "no bind used internally" etc,
which I actually don't find acceptable. I believe that sample code in a
specification should work with all compliant implementations, otherwise the
implementation is *not* specification compliant. Since the FTP Winsock.DLL
surely has access to all pending connection info it should be able to determine
at bind() time if there is a local address in use, and return EADDRINUSE if
necessary. What I had to do in my code is to have the bind() loop followed
by a connect() as it should be, and have another loop around all this to
try a new port if the connect() fails.

Just my 2 cents ...

/Thomas

---------------------------------------+--------------------------------------
Mail: Thomas Heil                      | EMail: BITNET: [e-mail]
      Forschungszentrum Juelich - ICG2 |      Internet: [e-mail]
      52425 Juelich                    | Phone: [phone]
      Germany                          | Fax:   [phone]
From [e-mail] Wed Apr  6 07:56:40 1994
Received: from post.demon.co.uk by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA01736; Wed, 6 Apr 1994 07:56:40 -0400
Received: from gateway.alex.com by post.demon.co.uk id ab18202;
          6 Apr 94 12:21 GMT-60:00
Return-Path: <[e-mail]>
Received: from SKID by woody.alex.com (4.1/SMI-4.1)
    id AA15772; Wed, 6 Apr 94 12:21:39 BST
Date: Wed, 6 Apr 94 12:21:39 BST
Message-Id: <[e-mail]>
X-Sender: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: [e-mail]
From: Bryan Boreham <[e-mail]>
Subject: Re: Closing and reusing sockets
X-Mailer: <PC Eudora Version 1.4>

>From Paul Brooks, [e-mail]:

>True, but you still have to think about the case where your local machine
>has closed the socket down OK, allowing you to BIND to the same
>port number in the future, but the REMOTE end still has the same
>port/address association valid, probably in TIMEWAIT state for two minutes.
>
>In this case, your bind() will succeed, but the remote end may well refuse
>the connection. WSAEADDRINUSE is a valid return from connect(),

Aha!  I was working on the assumption that EADDRINUSE referred to the
*local* address, not the remote address.  The spec doesn't specify --
is there any other explicit reference?  I see that Stevens "Unix Network
Programming" does use it as you describe in the rcmd example, page 570.

However, exactly the same circumstances didn't result in a failure at all
using the Trumpet stack.  I think I'll do some network sniffing to see if
I can spot what is different.

>as well as bind(). Also, if you set the socket option SO_REUSEADDR you will
>be allowed to bind() to the same port number, on the assumption that you want
>to connect to a different host/port from last time. If you try to connect()
>to the same host/port as last time, you'll get back WSAEADDRINUSE from
>connect().

This is not what we are doing.

>Maybe if you describe what you are actually trying to do to the list,

I gave a description in the first instance, but it was perhaps not very
precise.  The trouble is that we sell a development system, a programming
language, and therefore I have to cover all the cases that can arise when
third parties use our language to write systems.  I am not asking for
specific answers to work round one program failure, I am asking about how
stacks should behave *in* that failure mode.

Here is one specifc case: suppose a program uses rsh twice in
succession, something which is very easy in the Alex language.  We must
bind to a free reserved port locally, and we must connect to the same
remote port each time.  We would like to do this reliably on any of
the dozen or more Winsock stacks that our customers might use, with
the minimum of hack work-arounds that "just happen to fix it".

>instead of vague references to a private exchange,

I believe I quoted verbatim all references to the private exchange.

>we might be able to help you.

It all helps.  Thank you.

Bryan.